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Program  Description 

A.  System  Overview:  The  Cargo  Movement  Operations  System  (CMOS)  is  e.  top 
down  directed  program  (PE?  SECPEF  Memo,  7  Sep  8  4 )  that  will  contribute 
to  five  major  DOD  objectives:  1)  It  will  be  the  Air  Force  System  to 

implement  the  FY86  Defense  Guidance  mandated  Transpor tat i on 
Coordinators  -  Automated  Information  for  Movements  System  (TC-AIMS);  2) 
It  will  extend  Logistics  Marking  and  P.eadmg  Symbology  (LOGMAES) 
capability  to  basepTevel  transportation;  3)  It  will  introduce  Electronic 
Data  Interchange, .'CEDI )  to  base-level  transportation;  4)  It  will 
complement  the/'intrar.s  i  t  visibility  capability  present  in  other 
transpor  tat  igrn  systems;  and  5)  It  will  be  a  primary  source  of 
i n f ormat i orr  for  Air  Force  Logistics  Command,  Control,  and  Communications 
(LOGCj ) The  CMOS  Program  Management  Directive  *5272  (2)/38610F,  5  Dec 

86,  as  revised  21  Jun  88,  lays  out  an  incremental  development  strategy. 
Increment  I  will  automate  the  base  level  traffic  management  processes  of 
cargo  movement.  It  establishes  the  first  nine  electronic  interfaces 
with  other  transportation  systems  and  provides  a  solid  foundation  from 
which  to  add  the  enhancements  to  satisfy  the  requirements  of  increments 
II  anc  III.  Increment  II  will  add  the  capability  to  process  cargo  and 
passengers  in  a  unit  move  environment  and  report  the  movement  laterally 
and  upwardly.  Eleven  systemic  interfaces  will  be  initiated  in  this 
increment  to  augment  these  already  implemented.  Additional 
requirements,  known  as  Preplanned  Product  Improvements  (P3I) ,  will  be 
developed  in  Increment  III  on  a  schedule  that  has  yet  to  be  determined. 
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B.  Hardware  and  So  f  twar e  Env i r on men  t .  Hardware  and  non-development 

software  will  be  purchased  from  standard  government  contracts.  These 
are:  Desk  Top  III,  Standard  Multiuser  Small  Computer 

Requirements  Contract,  Unified  Local  Area  Network  Architecture,  and 
the  LOGMARS  Non-Tactical  Radio.  Development  Software  and  system  -> 

integration  services  will  be  provided  by  Evaluation  Research  Corporation 
International  through  a  GSA  contract  ( *GS -00K- 89 - AJDO 1 1 ,  21  Jun  89) . 


II.  Program  S tatus .  The  CMOS  Program  is  currently  in  the  Software 

Requirements  Analysis  phase.  The  Software  Requirements  Analysis  will 
conclude  with  the  Software  Specifications  Review,  15-18  Jan  90.  The  most 
recently  passed  milestone,  the  System  Design  Review  (11-13  Oct  89)  , 
established  the  Increment  I  functional  baseline.  The  next  major  program 
phase  will  be  the  Increment  II  System  Requirements  Analysis,  which  will 
begin  in  Nov  89  and  conclude  with  the  System  Requirements  Review  in  Jan 
90  . 

ITT  Analysis  f  or  Sc  f  two,  re  Sol  unions  . 

A.  Introduction .  A  solution  was  proposed  by  Evaluation  Research 
Corporation  and  selected  by  the  CMOS  Source  Selection  Board.  This  solution 
takes  advantage  of  the  Four t h -Gene r a t i on  Language  (4GL)  capabilities  provided 
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the  ORACLE  RDBMS  for  the  majority  of  the  software  development  effort 
timated  at  96  percent) .  The  remaining  4  percent  will  he  accomodated  by  the 
of  the  High  Order  Language  C.  What  follows  is  an  analysis  of  the  six 

tors  used  m  determining  the  selection  of  the  C  language  in  lieu  of  Ada : 

1.  S  v  stem  Life  Cycle  Cost  .  AFE  173-15  defines  life  cycle  cost  as  the 

net  present  value  of  the  total  cost  stream  of  an  alternative.  The  source 
selection  process  demonstrates  that  the  proposal  met  the  pertinent 
criteria  for  life  cycle  cost.  The  action  of  reevaluating  life  cycle  cost 
now  is  the  result  of  the  possibility  that  Ada  tools  will  become  available 
in  time  to  allow  CMOS  to  adhere  to  the  Ada  standard  instead  of  using  C 
language  as  originally  proposed.  The  CMOS  project  will  be  primarily 
developed  using  the  ORACLE  RDBMS.  However,  certain  systems  level 
programming  will  be  done  using  either  Ada  or  C  as  prescribed  by  the  RFP . 

The  purpose  of  this  examination  is  to  estimate  the  value  of  the  systems 

level  programming  for  the  C  and  Ada  languages  in  life  cycle  cost  terms. 

a.  C_  Language .  The  systems  level  programming  needed  represents  4 
percent  of  the  total  expense  attributed  to  software  development  for  CMOS 
as  originally  proposed.  The  incremental  cost  of  the  systems  level 
programming  can  then  be  defined  as  the  total  software  development  costs 
multiplied  by  the  percent  attributed  to  systems  level  programming.  This 
amount  represents  the  estimated  net  present  value  of  the  C  language 
portion  of  CMOS. 

b.  Ada .  In  a  March  1989  study  conducted  by  the  GAO,  systems 
development  and  maintenance  cost  savings  attributed  to  the  use  of  Ada 
could  not  be  substantiated  by  historical  data.  For  this  reason,  a 
conservative  estimate  of  Ada  driven  expense  would  be  approximately  the 
same  as  that  expected  for  C  language  as  defined  above.  There  are  no 
significant  cost  differences  between  C  and  Ada. 

2.  Sof  tware  Por tab i 1 i ty .  The  hardware  environment  of  CMOS  is  not 
expected  to  change  for  the  foreseeable  future.  Both  C  and  Ada  are 
designed  to  be  as  dev i ce - indepe nd en t  as  possible,  so  that  either  could  be 
readily  adapted  for  another  environment  when  hardware  replacement 
eventually  becomes  necessary.  The  C  language  environment  is  currently  the 
most  widely  used  for  open  systems  development,  so  its  availability  on  any 
future  hardware  platforms  is  highly  likely.  Neither  language  enjoys  an 
advantage  in  the  area  of  software  portability. 

3 .  So  f  tware  Reuse .  The  augmentation  provided  by  the  HOL  in  CMOS  is 
envisioned  primarily  in  the  'binding'  of  NDS  to  the  CMOS  applications 
developed  in  ORACLE.  The  small  amount  of  HOL  code  required  will , 
therefore,  be  rather  specialized  in  nature,  and  its  potential  for  reuse 
rather  limited.  The  Ada  language  is  somewhat  more  oriented  to  modular 
design  than  C,  but  the  C  language  makes  extensive  use  of  common  libraries 
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ar.d  ;h?.rpo  header  mtornation,  so  that  it  also  lends  itself  to  reuse  whsr 
possible.  No  measurable  differences  exist  between  C  and  Ada  in  software 


4  .  g r !  nvri nc<?  .  Eo  vh  1  ci n ’.i ct,^?o  t- 0  c r-s'r  1  $  c  f  rr.^ ?  t  ir.^  x,  0  dtoc ^ s a 
speed  requirements  of  CMOS.  The  extensive  memory  requirements  of  Ada 
present  a  potential  problem  on  the  Zenith  Z-248  PCs  which  are  to  be  used 
as  workstations,  because  of  the  large  <2  Megabyte  minimum)  size  of  the 
ORACLE  RDBMS.  The  use  of  a  C  language  environment  requires  much  less 
dedicated  memory.  As  a  result,  the  C  language  presents  much  less  of  a 
performance  risk. 

5.  Schedule  Risk.  Two  specific  concerns  in  the  area  of  schedule  risk 
■are  the  ORACLE/Ada  interfaces  and  the  Ada  compiler  for  the  3B2 . 

a.  At  present,  there  is  no  Ada  precompiler  for  the  ORACLE  RDBMS 

version  used  on  the  3B2 ,  although  one  is  slated  to  begin  Beta  testing  in 
December .  1989.  The  C  precompiler  is  already  included  as  part  of  the 

suite  of  HOL  interfaces  for  the  332  version  of  ORACLE.  Even  more 
significant  is  the  lack  of  any  existing  Ada  interface  for  the  MS-DOS 
version  of  ORACLE  to  be  used  on  the  PC  workstations.  Furthermore,  Oracle 
Corporation  has  no  current  undertakings  to  make  such  an  interface 
available.  The  3B2  and  Z-248  environments  each  have  available  proven  C 
language  interfaces  with  ORACLE. 

b.  The  Ada  compiler  for  the  3B2  has  not  yet  been  delivered  to  the 
government  for  testing,  whereas  the  C  language  compiler  has  been  availabi 
for  use  since  the  awara  of  the  Standard  Multiuser  Small  Computer 
Requirements  Contract  in  October  1988. 

c.  A  final  issue  regarding  schedule  risk  concerns  the 
recruitment  and  training  of  Ada  programmers.  With  regard  to  software 
development  productivity,  there  is  no  clear  distinction  that  can  be  made 
between  Ada  and  C.  Both  are  well  structured  modern  programming  languages 
which  have  a  variety  of  tools  available  to  enhance  the  development 
process.  However,  there  are  fewer  experienced  Ada  programmers  available. 
This  could  lead  to  a  reduction  in  software  productivity  incurred  by  the 
requirement  to  train  new  programmers  or  retrain  existing  staff. 

6.  Techn i cal  Risk.  A  report  published  in  March  1989  by  the  General 
Accounting  Office  which  examines  the  use  of  Ada  within  the  DOD  has  the 
following  statement  in  the  chapter  presenting  its  conclusions  and 
recommendations : 

Reliance  by  DOD  on  Ada  or  any  new  language  as  a  standard 
to  support  all  computer  systems  -  weapons  systems, 
mission-critical  systems,  and  information  management 
systems  -  carries  with  it  risks.  Programming  languages 
and  their  associated  software  development  tools  are 


complicated.  It  takes  time  and  considerable  experience 
using  them  in  a  variety  of  applications  before  they 
mature,  and  most  experts  agree  that  Ada  has  net  yet 
matured . 


In  contrast,  the  C  language  is  widely  used  for  a  multitude  of 
applications,  with  particularly  heavy  emphasis  on  system  level  functions. 
For  these  reasons,  Ada  presents  a  much  more  significant  technical  risk  in 
the  CMOS  development  effort. 

B.  Summary .  The  primary  drawback  inherent  in  the  use  of  Ada  as  the  KOL 
for  CMOS  development  lies  in  the  schedule  risks  it  presents.  The 
development  schedule  for  CMOS  is  highly  aggressive,  and  the  current 
non-availability  of  Ada  products  presents  a  major  obstacle  to  the  timely 
completion  of  the  tasks  required  for  schedule  milestones  to  be  met.  The 
use  of  C  language  in  place  of  Ada  has  several  distinct  benefits, 
primarily  in  the  areas  of  lower  schedule  and  technical  risk.  Given  an 
unlimited  amount  of  time  for  development,  the  use  of  either  would  serve 
equally  well.  However,  the  acute  need  of  the  transportation  community 
for  an  automated  system  makes  the  rapid  deployment  of  CMOS  a  prime 
concern  and  the  use  of  C  as  the  KOL  in  system  development  will  have  a 
direct  and  positive  impact  on  the  development  process. 
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